GitOps का उपयोग करके स्रोत पर सुरक्षा कैसे लागू करें

यदि आपके GitOps परिनियोजन मॉडल में सुरक्षा समस्याएँ हैं (उदाहरण के लिए, टाइपो के कारण गलत कॉन्फ़िगर की गई अनुमति), तो इसे तब तक प्रचारित किया जाएगा जब तक कि इसे रनटाइम पर उम्मीद से खोजा नहीं जाता है , जहां अधिकांश सुरक्षा ईवेंट स्कैन या पाए जाते हैं।

क्या होगा यदि आप स्रोत पर अपने बुनियादी ढांचे में संभावित सुरक्षा मुद्दों को ठीक कर सकते हैं?

आइए मूल बातें शुरू करें।

गिट क्या है?

गिट एक खुला स्रोत वितरित संस्करण नियंत्रण प्रणाली है । यह फाइलों में किए गए परिवर्तनों को ट्रैक करता है (आमतौर पर टेक्स्ट फाइलें जैसे स्रोत कोड) एक सहयोगी कार्य मॉडल को अनुमति और बढ़ावा देता है । यह आजकल वर्जन कंट्रोल सिस्टम में the_ de facto _standard है।

आप अपने लैपटॉप पर स्थानीय रूप से अपना खुद का गिट रेपो रख सकते हैं, इसे अपने सर्वर पर होस्ट कर सकते हैं, या कुछ प्रदाता जैसे गिटलैब या गिटहब का उपयोग कर सकते हैं।

रिपॉजिटरी (गिट-फ्लो, जीथब-फ्लो, आदि) को कैसे प्रबंधित किया जाए, इस पर अलग-अलग "प्रवाह" हैं, लेकिन गिट का उपयोग कैसे किया जाता है, इसका एक मूल उदाहरण कुछ इस तरह है: फाइलों में परिवर्तन उपयोगकर्ताओं द्वारा "प्रतिबद्ध" हैं भंडार को "फोर्किंग" करना और "शाखा" में उचित परिवर्तन करना।

फिर, उपयोगकर्ता रिपॉजिटरी में उन परिवर्तनों को शामिल करने के लिए एक अनुरोध (या तो "पुल अनुरोध", "मर्ज अनुरोध", या बस "एक पैच भेजें") बनाता है।

उसके बाद, आमतौर पर "मालिक" और अनुरोध करने वाले उपयोगकर्ता के बीच एक चर्चा होती है, और यदि सब कुछ ठीक हो जाता है तो परिवर्तन स्वीकार कर लिया जाता है और भंडार में जोड़ा जाता है।

नोट: यदि आप अधिक जानना चाहते हैं, तो यहां गिट पुल अनुरोध तंत्र के बारे में अधिक विस्तृत जानकारी है।

एक वास्तविक दुनिया का उदाहरण देखने के लिए, बस अपने पसंदीदा ओपन सोर्स GitLab या GitHub रिपॉजिटरी को ब्राउज़ करें और पुल रिक्वेस्ट (या मर्ज रिक्वेस्ट) टैब ब्राउज़ करें (या इसे मज़ेदार के लिए देखें)। आप प्रस्तावित परिवर्तन, टिप्पणियां, लेबल, जिन्होंने परिवर्तनों का प्रस्ताव रखा, प्रस्तावित परिवर्तनों के विरुद्ध सत्यापन चलाने वाले उपकरण, रिपॉजिटरी देखने वाले लोगों को भेजी गई सूचनाएं आदि देख सकते हैं।

GitOps क्या है?

सीधे शब्दों में कहें तो, GitOps सिर्फ एक कार्यप्रणाली है जो आपके सॉफ़्टवेयर परिसंपत्तियों के लिए सत्य के एकल स्रोत के रूप में git रिपॉजिटरी का उपयोग करती है ताकि आप अपने सॉफ़्टवेयर के लिए git परिनियोजन मॉडल (पुल अनुरोध, रोलबैक, अनुमोदन, आदि) का लाभ उठा सकें।

किताबें ( द पाथ टू गिटऑप्स , गिटऑप्स और कुबेरनेट्स या गिटऑप्स क्लाउड-नेटिव कंटीन्यूअस डिप्लॉयमेंट ), श्वेतपत्र , और अधिक ब्लॉग पोस्ट हैं जिन्हें हम गिनने के लिए प्रबंधित कर सकते हैं , लेकिन आइए हम गिटऑप्स के उद्देश्य के बारे में विस्तार से देखें कि चीजें कैसे विकसित हुईं पिछले पांच बरसों में।

क्लाउड से पहले, आपके एप्लिकेशन को होस्ट करने के लिए एक नया सर्वर जोड़ने में सप्ताह लगते थे। आपको अनुमति मांगनी थी, इसे खरीदना था और बहुत सारे मैन्युअल कार्य करने थे। फिर, वर्चुअलाइजेशन ने चीजों को बहुत आसान बना दिया। आप कुछ विशिष्टताओं के साथ एक वर्चुअल मशीन का अनुरोध करते हैं और कुछ मिनटों के बाद, आपके पास उस तक पहुंच होती है।

फिर, बादल। सर्वर, नेटवर्क, स्टोरेज और यहां तक कि डेटाबेस, मैसेजिंग क्यू, कंटेनर, मशीन लर्निंग स्टफ, सर्वरलेस… का अनुरोध करना सिर्फ एक एपीआई कॉल दूर है! आप इसके लिए अनुरोध करते हैं और कुछ सेकंड बाद, आप इसे वैसे ही प्राप्त करते हैं। आप जो उपयोग करते हैं उसके लिए आपको केवल भुगतान करना होगा। इसका मतलब यह भी है कि बुनियादी ढांचे को एपीआई कॉल करने वाले कोड के रूप में प्रबंधित किया जा सकता है ... और आप अपना कोड कहां स्टोर करते हैं? एक गिट भंडार (या किसी अन्य सामग्री संस्करण प्रणाली) में।

GitOps शब्द को 2017 में Weaveworks द्वारा वापस गढ़ा गया था, और OpenGitOps की व्याख्या करते हुए, एक GitOps सिस्टम निम्नलिखित सिद्धांतों पर आधारित है:

• घोषणात्मक : यह "क्या" परिभाषित करता है।
• संस्करणित और अपरिवर्तनीय : इसलिए "गिट।"
• स्वचालित रूप से खींचा गया : एक एजेंट वांछित स्थिति और कोड में होने वाले परिवर्तनों को देखता है।
• लगातार मेल मिलाप : क्या किसी ने कुबेरनेट्स का उल्लेख किया है?

GitOps कार्यप्रणाली का सार मूल रूप से आपके क्लस्टर पर चलने वाला एक कुबेरनेट्स नियंत्रक या नियंत्रक (या एजेंट) है जो इसके ऊपर चल रहे कुबेरनेट्स ऑब्जेक्ट को देखता है (एक CustomResource द्वारा परिभाषित) वर्तमान स्थिति की तुलना Git रेपो में निर्दिष्ट स्थिति से करता है । यदि यह मेल नहीं खाता है, तो यह रिपोजिटरी में पाए गए मैनिफेस्ट को लागू करके एप्लिकेशन को सुधारता है।

नोट: GitOps के लिए कुछ अलग दृष्टिकोण हैं, उदाहरण के लिए, पुश बनाम पुल, कॉन्फ़िगरेशन प्रबंधन को कैसे संभालना है, आदि। वे उन्नत विषय हैं, लेकिन अभी के लिए, मूल बातों से चिपके रहें।

निम्नलिखित आरेख एक सरलीकृत GitOps सिस्टम दिखाता है:

• उपयोगकर्ता द्वारा Git रिपॉजिटरी में एक कोड परिवर्तन प्रस्तुत किया जाता है।
• फिर, एप्लिकेशन में उन परिवर्तनों को शामिल करने के लिए रिपॉजिटरी पर एक प्रक्रिया शुरू की जाती है, जिसमें इसे मान्य करने के लिए उस नए कोड के खिलाफ ऑटोमेशन टूल चलाना शामिल है।
• एक बार सब कुछ हो जाने के बाद, GitOps एजेंट Kubernetes क्लस्टर में चल रहा है, जो रिपॉजिटरी को देख रहा है, वांछित स्थिति (रिपॉजिटरी में कोड) और वर्तमान स्थिति (कुबेरनेट्स क्लस्टर पर चलने वाली वस्तुओं) के बीच सामंजस्य स्थापित करता है।

Git पर आधारित होने का अर्थ है डेवलपर्स के लिए घर्षण रहित। उन्हें इंटरैक्ट करने के लिए किसी नए टूल के बारे में चिंता करने की ज़रूरत नहीं है, बल्कि गिट रिपॉजिटरी में कोड को प्रबंधित करने के लिए उपयोग की जाने वाली समान प्रथाओं को लागू करने की आवश्यकता नहीं है।

GitOps टूल के बारे में बोलते हुए, कुछ पहले से ही उपलब्ध हैं, जिनमें Flux या ArgoCD जैसे ओपन सोर्स टूल शामिल हैं, दोनों CNCF इनक्यूबेटिंग प्रोजेक्ट हैं ।

GitOps के माध्यम से एप्लिकेशन की परिभाषा कैसी दिखती है, इसे महसूस करने के लिए, यह Flux या ArgoCD द्वारा प्रबंधित एक साधारण एप्लिकेशन (GitHub रिपॉजिटरी में संग्रहीत) का एक उदाहरण है।

फ्लक्स के साथ:

 --- apiVersion: source.toolkit.fluxcd.io/v1beta2 kind: GitRepository metadata: name: my-example-app namespace: hello-world spec: interval: 30s ref: branch: master url: https://github.com/xxx/my-example-apps.git --- apiVersion: kustomize.toolkit.fluxcd.io/v1beta2 kind: Kustomization metadata: name: my-example-app namespace: hello-world spec: interval: 5m0s path: ./myapp prune: true sourceRef: kind: GitRepository name: my-example-app targetNamespace: hello-world

ArgoCD के साथ:

 apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: my-example-app namespace: hello-world spec: destination: namespace: my-example-app server: https://kubernetes.default.svc project: default source: path: myapp/ repoURL: https://github.com/xxx/my-example-apps.git targetRevision: HEAD syncPolicy: automated: {} syncOptions: - CreateNamespace=true

दोनों गिट रिपॉजिटरी का संदर्भ देते हैं जहां एप्लिकेशन मेनिफेस्ट संग्रहीत होते हैं (परिनियोजन), नामस्थान, और कुछ और विवरण।

GitOps बनाम IaC

इन्फ्रास्ट्रक्चर कोड के रूप में विभिन्न तकनीकों और उपकरणों का उपयोग करके आपके इंफ्रास्ट्रक्चर के बिल्डिंग ब्लॉक्स को कोड के रूप में मानने की एक पद्धति है। इसका मतलब यह है कि मैन्युअल रूप से अपने पसंदीदा इंफ्रास्ट्रक्चर प्रदाता वेब इंटरफेस के माध्यम से अपने बुनियादी ढांचे जैसे वीएम, कंटेनर, नेटवर्क या स्टोरेज को मैन्युअल रूप से बनाने के बजाय, आप उन्हें कोड के रूप में परिभाषित करते हैं, और फिर वे आपके द्वारा चुने गए टूल द्वारा बनाए/अपडेट/प्रबंधित होते हैं, जैसे टेराफॉर्म , क्रॉसप्लेन , या पुलुमी , दूसरों के बीच में।

लाभ बहुत बड़े हैं। आप अपने बुनियादी ढांचे का प्रबंधन कर सकते हैं जैसे कि यह कोड था (यह अब कोड है) और अपनी आधारभूत संरचना संपत्तियों के लिए अपने विकास सर्वोत्तम प्रथाओं (स्वचालन, परीक्षण, पता लगाने योग्यता, संस्करण नियंत्रण इत्यादि) का लाभ उठाएं। वास्तव में, एक शब्द के रूप में "इंफ्रास्ट्रक्चर के रूप में सॉफ्टवेयर" का उपयोग करने की प्रवृत्ति है क्योंकि यह सिर्फ कोड से कहीं अधिक है।

इस विषय पर बहुत सारी जानकारी है, लेकिन निम्नलिखित संसाधन एक अच्छा प्रारंभिक बिंदु है।

जैसा कि आप शायद समझ गए हैं, GitOps इन्फ्रास्ट्रक्चर को परिभाषित करने के लिए घोषणात्मक मॉडल के रूप में इन्फ्रास्ट्रक्चर को कोड के रूप में उपयोग करता है। वास्तव में, IaC GitOps के आधारशिलाओं में से एक है! लेकिन यह बहुत अधिक है क्योंकि IaC बाकी GitOps सिद्धांतों को अनिवार्य नहीं करता है।

GitOps बनाम DevOps

"DevOps" शब्द की बहुत सारी परिभाषाएँ हैं। यह निर्भर करता है कि आप किससे पूछते हैं लेकिन इसे सीधे शब्दों में कहें तो, "DevOps, घर्षण को कम करने वाले और उच्च गति के लिए सॉफ़्टवेयर बनाने और वितरित करने के लिए प्रथाओं और उपकरणों का संयोजन है।"

DevOps कार्यप्रणाली GitOps का लाभ उठा सकती है क्योंकि GitOps एक ऐसा ढांचा प्रदान करता है जो DevOps प्रथाओं से मेल खाता है लेकिन यह कड़ाई से आवश्यक नहीं है।

नोऑप्स के बारे में क्या?

NoOps को फॉरेस्टर द्वारा 2021 में गढ़ा गया था और यह संचालन को संभालने के लिए एक कट्टरपंथी दृष्टिकोण है जहां आईटी वातावरण सारगर्भित है और इस बिंदु पर स्वचालित है कि इसे मैन्युअल रूप से प्रबंधित करने की कोई आवश्यकता नहीं है।

GitOps Git रिपॉजिटरी में वांछित स्थिति वाले लोगों को हटाकर मैन्युअल परिवर्तनों को कम करने में मदद करता है, लेकिन संपूर्ण IT वातावरण में वास्तविक NoOps को लागू करना आज के वास्तविक लक्ष्य के बजाय एक आकांक्षात्मक लक्ष्य है ।

क्या GitOps सिर्फ Kubernetes के लिए है?

नहीं, कुबेरनेट्स, नियंत्रक पैटर्न और कुबेरनेट्स वस्तुओं को परिभाषित करने के लिए घोषणात्मक मॉडल GitOps कार्यप्रणाली के लिए एकदम सही मेल हैं, लेकिन इसका मतलब यह नहीं है कि GitOps कार्यप्रणाली Kubernetes के बिना लागू नहीं की जा सकती है। कुबेरनेट्स के बाहर GitOps का उपयोग करने में कुछ चुनौतियाँ हैं, जैसे कि idempotency को संभालना, संपत्ति को हटाना / बनाना, गुप्त प्रबंधन, आदि। लेकिन GitOps सिद्धांतों को Kubernetes के बिना लागू किया जा सकता है (और थोड़ी रचनात्मकता को लागू करना)।

गिटऑप्स और सुरक्षा

आइए अब सुरक्षा पहलुओं के बारे में बात करते हैं। अधिकांश सुरक्षा उपकरण रनटाइम पर संभावित कमजोरियों और मुद्दों का पता लगाते हैं (बहुत देर से)। उन्हें ठीक करने के लिए, या तो एक प्रतिक्रियाशील मैनुअल प्रक्रिया को निष्पादित करने की आवश्यकता होती है (उदाहरण के लिए, आपके k8s ऑब्जेक्ट में kubectl एडिट के साथ सीधे एक पैरामीटर को संशोधित करना) या आदर्श रूप से, फिक्स स्रोत पर होगा और आपकी आपूर्ति श्रृंखला के साथ प्रचारित किया जाएगा। इसे " शिफ्ट सिक्योरिटी लेफ्ट " कहा जाता है। समस्या को ठीक करने से लेकर उसके होने से पहले उसे ठीक करने तक बहुत देर हो चुकी है।

इसका मतलब यह नहीं है कि हर सुरक्षा समस्या को स्रोत पर ठीक किया जा सकता है, लेकिन सीधे स्रोत पर सुरक्षा परत जोड़ने से कुछ समस्याओं को रोका जा सकता है।

सबसे पहले, सामान्य सुरक्षा सिफारिशें लागू होती हैं।

• हमले की सतह को कम करें
• रहस्यों को एन्क्रिप्ट करें (बाहरी रहस्यों या मुहरबंद रहस्यों का उपयोग करके)
• नेटवर्क विभाजन
• आरबीएसी
• सॉफ्टवेयर को अपडेट रखें
• कम से कम विशेषाधिकार लागू करें
• मॉनिटर और माप
• …

आइए कुछ परिदृश्य देखें जहां GitOps कार्यप्रणाली सामान्य रूप से आपकी सुरक्षा में सुधार कर सकती है:

• मैन्युअल परिवर्तनों से बचें/अस्वीकार करें (बहाव से बचें) । गिट भंडार सत्य का स्रोत है। यदि आप एप्लिकेशन परिभाषा को संशोधित करने का प्रयास करते हैं, तो GitOps टूल Git रिपॉजिटरी में संग्रहीत संस्करण को लागू करके उन परिवर्तनों को वापस कर देगा।

• रोलबैक परिवर्तन । कल्पना करें कि आपने अपने एप्लिकेशन परिनियोजन में कुछ पैरामीटर को संशोधित करके एक विशिष्ट प्रतिबद्धता में संभावित सुरक्षा समस्या पेश की है। Git क्षमताओं का लाभ उठाते हुए, यदि आवश्यक हो तो आप सीधे स्रोत पर परिवर्तन को रोलबैक कर सकते हैं और GitOps टूल उपयोगकर्ता के संपर्क के बिना आपके एप्लिकेशन को फिर से तैनात करेगा।

• तेज उत्तर। यदि आप पाते हैं कि आप अपने एप्लिकेशन (जैसे, मारियाडीबी) में एक कमजोर कंटेनर छवि का उपयोग कर रहे हैं, तो आपको टैग को परिनियोजन फ़ाइल में अपडेट करने के लिए एक पीआर बनाने की आवश्यकता है और GitOps टूल एक नए परिनियोजन में नए टैग का उपयोग करेगा।

• पता लगाने की क्षमता। गिट क्षमताओं का उपयोग करके, आप आसानी से जांच सकते हैं कि फ़ाइल कब बदली गई थी, परिवर्तन स्वयं और उपयोगकर्ता जिसने परिवर्तनों को बढ़ावा दिया था। आपके पास निःशुल्क ऑडिट लॉग है ।

• आपदा बहाली। फिर से, Git भंडार सत्य का स्रोत है। यदि आपको अपने आवेदन को फिर से तैनात करने की आवश्यकता है क्योंकि कुछ हुआ है, तो परिभाषा है (निश्चित रूप से आपको अन्य सामग्री जैसे कि डेटा के लिए आपदा वसूली योजना की आवश्यकता है)।
• पहुँच नियंत्रण। आप अपने गिट रिपॉजिटरी पर अलग-अलग उपयोगकर्ताओं के लिए अलग-अलग अनुमतियां लागू कर सकते हैं और यहां तक कि नीतियां जैसे "केवल दो सकारात्मक समीक्षाओं के बाद परिवर्तन को मर्ज करें"।

वे लाभ आपकी सुरक्षा मुद्रा को बेहतर बनाने के लिए GitOps कार्यप्रणाली का उपयोग करने के औचित्य के लिए पर्याप्त हैं और वे बॉक्स से बाहर आ गए, लेकिन GitOps कुछ और चीजों का एक संयोजन है। हम और भी बहुत कुछ कर सकते हैं। GitHub, GitLab, और अन्य Git रिपॉजिटरी प्रदाता आपको अपने Git रिपॉजिटरी में किए गए परिवर्तनों के आधार पर क्रियाओं या पाइपलाइनों को चलाने की अनुमति देते हैं, जिसमें एक पुल अनुरोध भी शामिल है, इसलिए संभावनाएं अनंत हैं। कुछ उदाहरण:

• अस्तर। एप्लिकेशन की परिभाषा कोड है , क्या होगा यदि गलत सिंटैक्स, अनुपलब्ध पैरामीटर, और बहुत कुछ के लिए परिभाषा की जाँच की जाती है? ऐसे उपकरण हैं (जैसे मेगालिन्टर ) जिन्हें आपके द्वारा किए गए परिवर्तनों के विरुद्ध निष्पादित किया जा सकता है ताकि आप बाद में आश्चर्य से बच सकें।

• परिक्षण। आप अपने एप्लिकेशन को परिवर्तनों के साथ चलाने और इसके खिलाफ कुछ परीक्षण चलाने के लिए एक अस्थायी कुबेरनेट क्लस्टर के निर्माण को स्वचालित भी कर सकते हैं।

• भेद्यता स्कैनिंग । कंटेनर छवियों की जांच करके आप कमजोरियों के लिए उपयोग कर रहे हैं इससे पहले कि वे आपके वातावरण में तैनात हों।

• नीति के रूप में कोड। ओपीए का लाभ उठाते हुए, आप संभावित मुद्दों या कस्टम नीतियों की जांच के लिए अपने मैनिफेस्ट पर नीतियां भी लागू कर सकते हैं

अंतिम विचार

GitOps कार्यप्रणाली परिनियोजन मॉडल में कुछ सुधार लाती है और तालिका में सुरक्षा लाभ बिना किसी अन्य उपकरण को जोड़े ।

यह सीधे स्रोत कोड में "शिफ्ट लेफ्ट" लेयर जोड़कर सुरक्षा मुद्रा में सुधार करता है और पुल-अनुरोध मॉडल के लचीलेपन के लिए धन्यवाद, आप रनटाइम को प्रभावित या संशोधित किए बिना आसानी से अतिरिक्त सुरक्षा जांच जोड़ सकते हैं।

यहाँ भी प्रकाशित हो चुकी है।.